1. Field of the Invention
The present invention relates to the protection of memory data against illicit access, e.g. by a devious exploitation of a “dump” mode, while allowing normal use of that data and the possibility of testing its validity. For instance, the invention can be used to protect against unauthorized external access to source code stored in a read-only memory (ROM) of a microcontroller (MCU) or microprocessor controlled system.
Many programmed systems based on an MCU or microprocessor have a so-called user program stored as computer code in a ROM which usually forms an integral part of the MCU architecture. The user program contains the body of instructions necessary to execute functions for the system user, who may be an end user or equipment manufacturer. The user is only required to consider the user program as a functional unit that allows the controlled system to operate in the intended manner. In certain cases, the provider or proprietor of the user program does not wish to make the contents of the stored computer code accessible to the user, or indeed any other unauthorized party, e.g. to protect proprietary information, to prevent fraud, tampering, etc. In this respect, it can be noted that the normal execution of the user program does not make it possible to reconstitute its program code.
The problem is then to allow the programmed system to read the code stored in the memory for executing the user program, whilst preventing retrieval of that code data from outside the system.
At the same time, it is required to provide an external memory test to check whether there are any programming or data errors. In this case, the system enters into a “dump mode” to scan through the memory contents and deliver an indication of their validity, e.g., in the form of a checksum, to outside test equipment. It is important that this dump mode cannot be exploited by the user or any other unauthorized party to gain access to the memory contents.
2. Prior Art
Various techniques are known in the prior art for protecting stored data in such a context.
One approach involves means that act on the “chip select” (CS) or “chip enable” input of a ROM storing the protected data. The CS input is enabled in a user mode for executing the code, but disenabled when the ROM is set to a test mode by the user, i.e. outside the allowed test conditions. This is generally achieved by means of a fusible link in the ROM. The link is made to by-pass a readout protection, so preventing the chip select input CS from being disenabled. In this way, the chip manufacturer or programmer can use the test option to read out the memory contents (for instance the program code) to check that there are no errors. Once this initial test is completed, the fusible link is blown, e.g. by applying an appropriate high voltage pulse, so that from then on the protection can no longer be bypassed, i.e. the CS input shall be automatically disenabled whenever the test mode is selected. The memory can then only be accessed for executing the code.
This approach, which constitutes a static option, has the disadvantage of involving additional process steps for implementing the fusible link, adversely affecting costs and production yield. It also has the drawback of disenabling the test mode data readout irrevocably, which is not always desirable.
Another known approach is to establish a confidential code for accessing the test mode, or more generally a mode that allows direct access to the ROM data contents. The code is entered e.g. as a combination of logic states applied to different input pins of the system, or a sequence of logic states applied to a predetermined pin. It is less secure than a fusible link and often inadequate to safeguard the memory contents.
One of the memory modes used for such testing, and which thus needs to be protected, is known as the “dump mode”. This mode allows all the memory data to be read out sequentially, normally by incrementing or decrementing through successive memory addresses. At each clock cycle, a byte of memory content from a current address is thus sent through an internal data bus, e.g. for processing by a checksum calculation circuit within the programmed system. The checksum calculation circuit performs an iterative algorithm on each byte received to produce a cumulative checksum value. This value is delivered outside the system so it can be compared with an expected value. If the two values are equal, then it is deduced that the memory contents are valid, otherwise the disparity indicates that at least one of the stored bytes was incorrect.
When—as is normally the case—the checksum is performed on a substantial number of bytes, it is not possible to deduce the specific contents of each of these bytes from the value of the checksum delivered by the system.
FIG. 1 is a flowchart which traces the main aspects of a classical dump mode.
The ROM is initially set to be in a so-called “inactive” option (step S1). This option corresponds to a choice submitted by the proprietor of the program entered in the ROM. The inactive option allows a normal dump to be made for reading out the memory contents.
Because the normal dump can be started from any memory address, the latter needs to be specified externally (step S2).
Next, the mode is selected to indicate the way in which the ROM is tested (step S4).
After the above initialization steps, a checksum value stored in an internal checksum calculation circuit is reset to zero (step S6) before starting the dump, to ensure that the checksum calculation from a known reference value.
Then, the ROM chip select CS is enabled (step S8) through a designated pin or command, enabling the readout to be blocked or not.
The inventors have found that the normal dump mode of the prior art makes the memory contents vulnerable to attacks.
Indeed, because the checksum can be started from any address, and jumps can be made between addresses, it is possible to perform a checksum on selected small portions of the memory, e.g. containing just one or two bytes. The value of the checksum can in this case reveal the exact contents of the byte(s), given the very small sample involved and the fact that the checksum algorithms used are generally known.
Secondly, while a normal dump resets the checksum at the start of the algorithm (step S6), no similar provision is made when the programmed system is reset. In the latter case, the system exits from the normal dump mode and the current value of the checksum becomes available externally, just as if the checksum were completed. This condition can also be exploited to pick an arbitrary end point address for the checksum calculation, simply by selecting when—in terms of clock cycles—to apply a system reset.
In this way, an attacker can use the dump mode option to trace back piece-by-piece the bytes stored in the memory, and thereby obtain e.g. a program code.